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Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2005). 

Abstract 
This memo defines a new Vendor-Specific Information suboption for the 
Dynamic Host Configuration Protocol's (DHCP) relay agent information 
option. The suboption allows a DHCP relay agent to include vendor- 
specific information in the DHCP messages it forwards, as configured 


by its administrator. 
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Les 


Introduction 


DHCP (RFC 2131 [2]) provides IP addresses and configuration 
information for IPv4 clients. It includes a relay agent capability, 
in which processes within the network infrastructure receive 
broadcast messages from clients and forward them to DHCP servers as 
unicast messages. In network environments like DOCSIS data-over- 
cable and xDSL, for example, it has proven useful for the relay agent 
to add information to the DHCP message before forwarding it, using 
the relay agent information option (RFC 3046 [3]). 


Servers that recognize the relay agent option echo it back in their 
replies, and some of the information that relays add may be used to 
help an edge device efficiently return replies to clients. The 
information that relays supply can also be used in the server's 
decision making about the addresses and configuration parameters that 
the client should receive. 


In many environments, it's desirable to associate some vendor- or 
provider-specific information with the clients' DHCP messages. This 
is often done using the relay agent information option. RFC 3046 
defines Remote-ID and Circuit-ID sub-options that are used to carry 
such information. The values of those suboptions, however, are 
usually based on some network resource, such as an IP address of a 
network access device, an ATM Virtual Circuit identifier, or a DOCSIS 
cable-modem identifier. As a result, the values carried in these 
suboptions are dependent on the physical network configuration. The 
Vendor-Specific suboption allows administrators to associate other 
useful data with relayed DHCP messages. 


Requirements Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [1]. 


The Vendor-Specific Suboption 
This memo defines a new DHCP relay agent option suboption that 


carries vendor-defined data. The suboption takes a form similar to 
the Vendor-Identifying, Vendor-Specific Option [7]. 
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0 1 2 3 
0. 1:239 4.5 6.7.8 .9.0 1.2 345.06 7 89 9-0 12 3.4 5 6 78.9 0 4 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Code | Length | Enterprise Number1 

+-+-+-+-+-+-+-+-+-+-+-+-+- +++ 
| | DataLen1 | | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ + 
\ Suboption Datal X 


— —————————— — — — — — — M 
| Enterprise Number2 | 
+-+-+-+-+-+-+-+-+-+-+-+-+ +++ 
| DataLen2 Suboption Data2 

—-4-—R----—R--—4-4-4-—-4-4--—-4-4--—-4-94----4—4--4-4 
\ 


\ 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
The Code for the suboption is 9. 


The one-byte Length field is the length of the data carried in the 
suboption, in bytes. The length includes the length of the first 
Enterprise Number; the minimum length is 4 bytes. 


"Enterprise NumberN" is a vendor's Enterprise Number as registered 
with IANA [4]. It is a four-byte integer value in network byte- 
order. 


DataLenN is the length of the data associated with the Enterprise 
Number. 


The Suboption Data is an opaque sequence of bytes. 


The Vendor-Specific suboption includes at least one Enterprise Number 
and carries opaque data defined by the organization identified by the 
Enterprise Number. A relay may include data associated with more 
than one vendor's Enterprise Number within a single instance of the 
Suboption. 


Of course, the Vendor-Specific data are vendor-specific. This 
Specification does not establish any requirements on the data in the 
suboption. Vendors who make use of this suboption are encouraged to 
document their usage in order to make interoperability possible. 
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4. 


Relay Agent Behavior 


DHCP relay agents MAY be configured to include Vendor-Specific 
suboptions if they include a relay agent information option in 
relayed DHCP messages. The suboptions' types and data are assigned 
and configured through mechanisms that are outside the scope of this 
memo. 


Relay implementors are encouraged to offer their administrators a 
means of configuring what data can be included in this suboption, and 
to document what they are capable of. 


DHCP Server Behavior 


This suboption provides additional information to the DHCP server. 
The DHCP server, if it is configured to support this suboption, may 
use this information, in addition to other relay agent option data 
and other options included in the DHCP client messages, in order to 
assign an IP address and/or other configuration parameters to the 
client. There is no special additional processing for this 
suboption. 


Security Considerations 


Message authentication in DHCP for intradomain use, where the out- 
of-band exchange of a shared secret is feasible, is defined in RFC 
3118 [5]. Potential exposures to attack are discussed in section 7 
of the DHCP protocol specification in RFC 2131 [2]. 


The DHCP relay agent option depends on a trusted relationship between 
the DHCP relay agent and the server, as described in section 5 of RFC 
3046. Fraudulent relay agent option data could potentially lead to 
theft-of-service or exhaustion of limited resources (like IP 
addresses) by unauthorized clients. A host that tampered with relay 
agent data associated with another host's DHCP messages could deny 
service to that host, or interfere with its operation by leading the 
DHCP server to assign it inappropriate configuration parameters. 


While the introduction of fraudulent relay agent options can be 
prevented by a perimeter defense that blocks these options unless the 
relay agent is trusted, a deeper defense using authentication for 
relay agent options via the Authentication Suboption [6] SHOULD be 
deployed as well. 


There are several data in a DHCP message that convey information that 
may identify an individual host on the network. These include the 
chaddr, the client-id option, and the hostname and client-fqdn 
options. Depending on the type of data included, the Vendor-Specific 
suboption may also convey information that identifies a specific host 
or a specific user on the network. In practice, this information 
isn't exposed outside the internal service-provider network, where 
DHCP messages are usually confined. Administrators who configure 
data that will be used in DHCP Vendor-Specific suboptions should be 
careful to use data that are appropriate for the types of networks 
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they administer. If DHCP messages travel outside the service- 
provider's own network, or if the suboption values may become visible 
to other users, it may raise privacy concerns for the access provider 
or service provider. 


7. IANA Considerations 
The IANA has assigned the suboption number 9 for the Vendor-Specific 
Information Suboption from the DHCP Relay Agent Information Option 
[3] suboption number space. 
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